The present invention relates generally to data processing and interactive computer applications, and more particularly, to application state checkpointing.
In a traditional web application, the browser displays the user interface and mainly passes user input to a back-end server that is executing the core application logic. This ensures that web applications can run on base configurations of most browsers but can result in an inferior user experience when compared to an average desktop application. This problem arises because base configurations of browsers do not have access to a rich set of user interface elements, and the browser is locked to application code and state residing on a remote server. Most user input causes a mandatory page load, making the application feel less responsive and more disruptive for the user.
Modern applications leverage the browser's ability to execute Javascript and communicate with the server using asynchronous messaging. Application code and application state can be moved from the server to the browser, resulting in applications that have richer interfaces and improved responsiveness. Code executing in the browser has much more autonomy to manage the application state separate from the server-side components. For example, browser-based office applications may only require a server to store data documents while the browser handles all other document management operations. This has greatly improved user experience.
Because of the large improvement in user experience, it is likely that applications which rely heavily on script executing in a browser will be an important, if not dominant, design for web applications. This has implications in browser design, application programming models, and performance enhancing strategies for the web infrastructure. One such implication is the ability for these applications to checkpoint their states. Browser applications are subject to various failures, and there exists a need to capture all the necessary state information needed to seamlessly restart, a browser application on demand. Checkpointing is also fundamental for enabling other state management services, such as application suspensions and resumptions and operation undoes and redoes.
Applications built using browser-based technologies increasingly need to manage application state on the client-side. Unfortunately, the browser is mostly optimized to render static documents and lacks the proper programming and user abstractions for managing application state. Application state management within the browser itself is an afterthought, since traditionally all application state management has been done outside the browser. Programming an application for the browser requires extensive knowledge of workarounds to achieve consistent results. The browser's document model of programming applications is incompatible with common application programming models. The browser freely mixes view components, executable script, and data into a single renderable document, creating an application structure that is a patchwork of sections, each having their own visual components, data, and script.
Developers wishing to add checkpointing services to the application state must manually interpret the patchwork of code that may be spread over several files. This interpretation includes identifying what state needs to be captured in the checkpoint and manually wiring the application to use persistence services that may not be available at runtime.
Current browser-based facilities for managing application state rely on custom coded or limited script APIs and browser-based services for persistent data. While both are appropriate for relatively passive web browsing, more complex browser based application levy new requirements on application-state management, such as state versioning, handling intermittent connectivity, and synchronization.
Thus, there exists a need for browser enhancement to provide both developers and users with a way to mange client-side state management.